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D 

Abstract —Effective collaboration is a key factor in the success 
of a software project developed by a team. In this work, we sug¬ 
gest the approach of Synchronized Software Development (SSD), 
which promotes a new mechanism of collaboration in general, 
and for code synchronization in particular. In SSD, code changes 
made by one developer are automatically propagated to others 
as long as they keep the code free of compilation errors. Changes 
that introduce compilation errors are not propagated until the 
errors are fixed. Moreover, other developers are restricted from 
concurrently editing the entities involved in these changes. While 
in this state, developers are, however, free to modify the rest of 
the entities. 

The novelty of our approach is that it actively synchronizes 
developers with the latest error free version of the source code, 
preventing possible conflicts and merges that may arise due to 
concurrent changes made by fellow team members. SSD also 
allows for a more transparent an practically near real time 
awareness of new code that is being introduced by multiple 
developers. We built CSI (Code Synchronizing Intelligence), a 
prototype demonstrating key features of SSD. 

Index Terms —collaboration; change; awareness; conflicts; 
merge; 

I. Introduction 

Modern software projects involve multiple developers col- 
laboratively working on the same codebase. In fact, parallel 
development has become the norm rather an exception m. 
The task of sharing a codebase repository is usually carried 
out by a Software Configuration Management system (SCM) 
n, in, m. The SCM system maintains all files that 
comprise the software project, and serves as the only version 
controlling mechanism through which developers share code 
|6l. The SCM tools employ a common checkin / checkout 
model according to which a change will become visible to 
others, only after the developer who made it checks in his code 
to the shared repository. A direct implication of this model 
is that code conflicts will only be discovered post factum, 
when a developer tries to checkin the already conflicting code. 
Once aware of the conflict the developer is forced to resolve 
it by means of merging his version with the repository’s one. 
Such manual merges are considered both time consuming and 
error prone Q, m- This is a definite limitation of the current 
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checkin / checkout model. Inspired by Google Docs in, we 
envision a development environment that provides similar real 
time collaborative editing capabilities for code development. 

II. Related work 

A number of tools have been suggested so as to address the 
code conflicts issue, and have mostly concentrated on increas¬ 
ing developers’ awareness of the activities performed by fellow 
team members. Such tools usually come either as a plug-in 
integrated into the Integrated Development Environment (IDE) 
(Syde d, Lighthouse mi) or as a standalone application 
(Palantir E), FASTDash El). CollabVS (HI extends the 
Standard Visual Studio user interface with collaboration ori¬ 
ented features such as chat, video, and audio streams on top of 
its conflict detection mechanisms. CloudStudio ca suggests 
a concept of ’’cloud-based development”, and replaces the 
explicit checkin / checkout model with interactive editing and 
real-time conflict tracking and management. One of the main 
goals of these tools is to provide developers with relevant 
information so as to assist them in avoiding code conflicts. 
The described tools share a common principle, they collect 
relevant information and present it to the developer. It is up 
to the developer to utilize this information and perform (or 
refrain from performing) a particular set of actions in order to 
prevent conflicts and promote collaboration. The developer is 
only shown the path, yet he is the one who has to walk it. 

Our work addresses the difference between knowing the 
path and walking the path M- The suggested approach. 
Synchronized Software Development (SSD), forcibly turns 
concurrent changes into sequential ones, by allowing only one 
developer to edit any given entity (e.g. method) at any given 
time. Other developers are blocked from concurrently editing 
that particular entity. While blocked they may, however, edit 
other entities in the code. In addition to the trivial case of 
concurrently editing the same entity, SSD also aims to detect 
indirectly conflicting (concurrent) changes that may affect 
one another, resulting in a conflict. Eor instance, changing 
a method’s name at one site, while using the old method’s 
name at another. SSD strives to enforce conflict prevention by 
means of fine grained restrictions on entity editing, and thus 
prevent the conflicts (and manual merges) originating from the 


checkin / checkout synchronization model typically employed 
by current SCM systems. 

III. Motivating Use Case 

We call the state in which the code fails to compile 
unhuildahle state, and the state in which the code successfully 
compiles a buildable state. 

We shall now analyze a use case demonstrating SSD in a 
real life scenario, accompanied with some screenshots from 
CSI, our SSD prototype. 

1) Two developers, Alice and Bob begin in the same file 
state. See figure section 1. 

2) Bob intends to add a new parameter, ’’newParam”, of 
type int to the method ”Foo”. Bob begins typing in his 
change, but mistakenly types ”in newParam”, missing 
the ”t” at the end of ”int”. 

3) Not being aware of his mistyping. Bob also changes the 
name of the method from ”Foo” to ’’Fool”. At this stage 
Bob has a new name for the method ”Foo” (i.e. ’’Fool”) 
and an additional, incorrect parameter definition. These 
changes render the file state unbuildable. Since the code 
state is currently unbuildable, none of the changes Bob 
has made are propagated to Alice. See figure section 
2 . 

4) Meanwhile, Alice intends to change the method ”Foo” 
to ”Foo2”. She is currently unaware that Bob has already 
changed this method’s name to ’’Fool”, and in the file 
version she currently has, the method’s name is still 
”Foo”. Alice begins changing the name of ”Foo” to 
”Foo2”, say by typing an additional ”2” at the end of the 
”Foo” string in the method definition, and is immediately 
warned that the current method is locked for editing by 
another developer (Bob). 

5) Alice is now made aware that the method is undergoing 
changes by some other developer (Bob), and is forced to 
wait till these changes are complete, avoiding the conflict 
that would have otherwise been introduced due to fact 
they both had changed the method’s name. See figure 
section 3. 

6) Once Bob adds the ”t” to the mistyped ”in”, his code 
becomes buildable, and is instantly propagated to Alice, 
which gets the new method name, with the additional 
parameter added by Bob. Alice may now commence the 
change she has intended. See figure section 4. 

It is worth noting that SSD works on the fly, as developers 
type in code. Neither Alice nor Bob has to actively save their 
file in order for SSD to perform. This may be witnessed by 
the asterisk symbol near the file name at the top of the editing 
tab in the Eclipse IDE, which indicates that the file at hand 
has not been saved yet and all changes are currently buffered 
in memory, see figures 

In a typical SCM system, such a conflict would only be 
discovered post factum, when a developer would try to checkin 
an already conflicting code version. In an SSD system the 
conflict is discovered at the time of producing conflicting 


code, while in current SCM systems it is only discovered after 
it has been checked in to the SCM. 

The key concept of an SSD system is that it is aware of all 
changes currently carried by all team members. Thus, once the 
(chronologically) first developer begins changing the method’s 
name, the SSD system locks the method element for editing 
by other developers. When another developer tries to change 
the same method, the SSD system will notify him that the 
element he’s trying to edit is already being edited. He should 
then wait until the undergoing change is complete, and only 
then introduce his own changes. By means of locking we aim 
at preventing concurrent, conflicting changes, that otherwise 
might have resulted in a conflict. However, the locking is so 
fine grained that we expect it to be practically transparent 
to developers, and they will only be aware of it in case it 
intervenes to prevent a highly probable conflict. 

The concept demonstrated in the use case we described 
applies to a wide variety of changes: introducing new methods, 
changing existing method’s name, changing existing method’s 
body, and so on. An SSD system should support all code 
editing operations available in a standard IDE. 

IV. Dependency detection to the aid oe conflicts 

PREVENTION 

We believe it is highly undesirable for developers to make 
design related decisions based on stale code. Our fundamental 
assumption is that while coding, a developer would rather wait 
(obviously, within reason), than engage in a manual merge 
process incurred by possible code conflicts. Our efforts are 
proactive, directed at preventing conflicts before they actually 
occur. 

We establish the notion of element (i.e.. Abstract Syntax 
Tree nodes (AST)) dependency. Elements Ei, E 2 are depen¬ 
dent if one of the following holds: 

1 ) E\ = E 2 . 

2) Ei^E2 have a common ancestor of type method or 
statement in the AST . 

3) El references F^ 2 ’s binding or vice versa (e.g., Ei = 
aMemberEield E 1; E 2 = int aMemberEield]). 

We argue that in order to prevent conflicts, no dependent 
elements should be subject to concurrent editing. 

The first case implies that no single element may be 
concurrently edited. 

The second case deals with concurrent editing of elements 
such as statements inside methods, or parameters in method 
invocations taking place inside the body block of another 
method. Theoretically, an SSD system could allow concurrent 
editing of statements in the same method, however, we believe 
this is not a good practice since it may lead to inconsistencies 
in the method’s logic. 

We demonstrate the third case with an example. Suppose 
we have a variable: 

int someVar; 

denoted by Ei, and a statement: 

int otherVar = someVar; 


Fig. 1. 

(1) Alice and Bob begin in the same state. 

(2) Bob introduces some changes. Method’s name is changed, and the new parameter has an invalid type. 
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Fig. 2. 

(3) Alice’s trial to edit the method’s name prompts the system to block her change, and display an alert. 
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denoted by E 2 . Let denote Ei element’s copy at devel¬ 
oper j’s site (i.e., Ei^^ is EEs copy at developer2’s site). 
Suppose now, that developerl renames Ei^_^ to: 

int newSomeVar; 

while at the same time, developer2 changes E 2 ^^ to: 

int otherVar = someVar -h 1; 

(before either change is propagated to the other site). Note that 
developerl’s renaming of Ei^^ results in a cascading change 
to E 2 a^ in order to make the code buildable. E 2 ^^ is now: 

int otherVar = new SomeVar; 

and it is in conflict with E 2 ^^, which is: 

int otherVar = someVar -h 1; 

Once such a state is reached, no matter what order the changes 
are propagated in, a conflict is inevitable, E 2 ^^ ^ E 2 ^^. The 
third element dependency condition above aims to prevent 
such cases. 

V. CSI - An SSD prototype 

We’ve begun implementing CSI (Code Synchronizing In¬ 
telligence), an SSD prototype plug in for the Eclipse IDE. 
CSI uses the Java Model [TtI offered by the Eclipse JDT 
(Java Development tools) in order to be notified of changes 
(introduction, deletion and modification of Java elements, 
which in turn may be classes, methods, member variables and 


so on) made to the model representing the program structure. 
The Java Model plays an important role in tracking changes 
on a semantical level, rather than observing textual changes, 
which is a key principle of SSD. 

VI. Discussion & Limitations 

It is crucial to determine the dependent elements as soon 
as possible in order to enforce locking in near real time. Any 
delay in doing so may result in a conflict due to unrestricted 
concurrent editing. We’re investigating ways to employ AST 
resolution on the fly (as code is written) in order to detect 
complex element dependency, while incurring minimal per¬ 
formance cost. 

Developer’s privacy should also be taken into account. A 
developer may want to go ’’off the record” whenever he wishes 
to delay the propagation of his changes, despite the fact 
that technically, they can be propagated immediately. Local 
testing is great motivation for going off record. However, this 
increases the chance of introducing a conflict once going back 
”on record”, since during the off record period the developer 
is unsupervised by the locking mechanism. 

VII. Impact and Euture Work 

SSD combined with cloud computing in general, and cloud- 
based development ca in particular, will result in a powerful, 
collaboration oriented IDE, provided in a form of Software 
as a Service (SaaS) ca. This, in turn, may change the 
current perception of an IDE, and present opportunities for 
new paradigms in the field of software development. 












An example of such a paradigm is near real time automated 
unit testing. Near real time code propagation presents the 
opportunity for running automated unit test suites on code that 
has just been written (long before it is checked-in to the SCM). 
To reduce running times, regression test selection algorithms 
and techniques can be employed. Near real time regres¬ 
sion testing will assist in a considerably earlier regression bug 
detection, than in a traditional checkin / checkout model. This 
in turn, will lead to a cost reduction in software development 
projects 1^ . 

SSD can change the rules of known practices like Pair 
Programming, challenging the traditional separation between 
the driver-navigator roles. 

The nature of SSD blurs the boundaries between distributed 
and non distributed software development, enabling close col¬ 
laboration even between geographically separated developers. 

We intend to elaborate our research and extend our vision of 
software development environments in the presence of SSD. 
Our future efforts will be dedicated to conducting further user 
studies and experiments in order to devise SSD best practices. 
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